home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Gold Collection / Software Vault - The Gold Collection (American Databankers) (1993).ISO / cdr11 / rrhelp.zip / RRMAST.TCH
Text File  |  1993-06-17  |  11KB  |  303 lines
  1. To:   ALL                      
  2. From: KENTON HENSLEY           
  3. Subj: UPDTE FLD IN FIL DUR ENTR
  4. Conf: ZACHARY 5 (2)                 Msg # 1515   
  5. Date: 05/18/92                      (PUBLIC)
  6.  
  7. To Barbara Dunn or anyone: 
  8.  
  9. I'm using R&R and want to give the user a choice of destination for the 
  10. report they are going to print.  I have defined a B-type PROC with 
  11. a screen that provides access to the R&R RRUNIN.DBF for the report name 
  12. (RI_REPORT) and the printer destination field (RI_PRINTER).  RI_PRINTER 
  13. is defined as an O-type.  The last field in the procedure is a U-type 
  14. field that calls my function which calls R&R. 
  15.  
  16. The difficulty is that after the user picks a destination for the 
  17. report (1,2 or D for Display) the RRUNIN.DBF must be updated 
  18. immediately.  How is this done?  I've tried adding a line to the U-type 
  19. field: 
  20.  
  21. _FIELD->RI_PRINTER:=mri_printer or 
  22. RRUNIN->RI_PRINTER:=mri_printer 
  23.  
  24. - neither of these works and I've phutsed(?) with some frustration with 
  25. several other ideas.  What do I do? 
  26.  
  27. Thanks for any help, 
  28. Kenton 
  29.  
  30.  
  31.  
  32.  
  33. ▀ Message Sent Via THE INTERCOM ver. 1.09a Zachary Speaks! ▀ 
  34.  
  35. To:   KENTON HENSLEY           
  36. From: BOB STEWART              
  37. Subj: UPDTE FLD IN FIL DUR ENTR
  38. Conf: ZACHARY 5 (2)                 Msg # 1519   
  39. Date: 05/18/92                      (PUBLIC)
  40.  
  41. Kenton, 
  42.  
  43.    Call a "U" type field after you do the pop-up.  Use the RRUNIN.dbf
  44. and replace the value of RI_PRINTER with the value. 
  45.  
  46.    I normally use a single record database to do the work for me.  I
  47. save any report filter parameters and the printer destination. 
  48. Remember, if it is on a network use the file in exclusive mode. 
  49.  
  50. The following is the code extract from one of my "U" type fields: 
  51.  
  52. save screen 
  53. select 2 
  54. use PRTINVD exclusive 
  55. select 1 
  56. use RRUNIN exclusive 
  57. go 13 
  58. replace RI_QUERY with "O" 
  59. replace RI_PRINTER with PRTINVD->printer 
  60. replace RI_FILTER with "dtoc(SALEORD->ShipDate) >= '" + 
  61.     dtoc(PRTINVD->SDate) + "' .and. dtoc(SALEORD->ShipDate) <= '" +
  62.     dtoc(PRTINVD->EDate) + "'"
  63. close databases 
  64. run rruntime rrunin 13 
  65. restore screen 
  66.  
  67. Before you close the databases you can reset the values in the PRTINVD 
  68. file so you can reprint the same range over again. 
  69.  
  70.  
  71.    Hope that this is a help.
  72.  
  73. Bob 
  74.  
  75.  
  76. ▀ Message Sent Via THE INTERCOM ver. 1.09 Zachary Speaks! ▀ 
  77.  
  78. To:   KENTON HENSLEY           
  79. From: ART VANHECKE             
  80. Subj: UPDTE FLD IN FIL DUR ENTR
  81. Conf: ZACHARY 5 (2)                 Msg # 1521   
  82. Date: 05/18/92                      (PUBLIC)
  83.  
  84. >is defined as an O-type.  The last field in the procedure is a U-type 
  85. >field that calls my function which calls R&R. 
  86. > 
  87. >The difficulty is that after the user picks a destination for the 
  88. >report (1,2 or D for Display) the RRUNIN.DBF must be updated 
  89. >immediately.  How is this done?  I've tried adding a line to the U-ty 
  90.  
  91. Kenton, 
  92.  
  93. I think you have the right idea, but your timing is off.  Leave the 
  94. b-type alone, it seems to be working ok. 
  95.  
  96. Change the execution point of the u-type field that calls R&R to EX, 
  97. that's AFTER EXITING the procedure. 
  98.  
  99. The idea of accessing the RRUNIN.dbf file with the B-type is good.  In 
  100. addition to allowing you to change the file easily, it will also 
  101. protect the program if someone inadvertantly deletes the RRUNIN.dbf 
  102. (Zach will recreate the deleted file).  I wouldn't say it if it hadn't 
  103. happened. 
  104.  
  105. --Art 
  106.  
  107.  
  108. ▀ Message Sent Via THE INTERCOM ver. 1.09 Zachary Speaks! ▀ 
  109.  
  110.  
  111. To:   DICK BERTI               
  112. From: RICHARD HAMILTON         
  113. Subj: ZACHARY SPEAKS PROBS     
  114. Conf: MAIN BOARD (0)                Msg # 3841   
  115. Date: 04/30/92                      (PUBLIC)
  116.  
  117. We've found the R&R system, with RRUNIN.DBF defined in Zach, works 
  118. great because you can then do the reports with an E-procedure and look 
  119. up things like the report name from the RRUNIN via a standard Zach file 
  120. validation. 
  121.  
  122. Hide the RRUNIN itself from the user by making it a rather elusive hot 
  123. key (like ALT-F5) and if you want more protection add either a complete 
  124. security system or a little tiny one known only to you, such as a 
  125. condition for access: 
  126.  
  127. if(zget(23,2,'    ','Enter Password','@!')='RHOK',.t., 
  128. zerrorbeep('Invalid Password')) 
  129.  
  130. (This, of course, is all typed on one line in the Condition for Access 
  131. field.) 
  132.  
  133. This worked very well for us, although the password is hard-coded 
  134. (RHOK), but if someone really wants to get in and screw things up I'm 
  135. sure they could anyway, what with dBase and all. 
  136.  
  137. Richard 
  138.  
  139.  
  140. ▀ Message Sent Via THE INTERCOM ver. 1.09 Zachary Speaks! ▀ 
  141.  
  142. To:   DICK BERTI               
  143. From: ART VANHECKE             
  144. Subj: ZACHARY SPEAKS PROBS     
  145. Conf: MAIN BOARD (0)                Msg # 3968   
  146. Date: 05/04/92                      (PUBLIC)
  147.  
  148. Dick, 
  149.  
  150. I have always used R&R as my report writer for Zach.  I generally use 
  151. the same format as you, but I usually let the user do as many reports 
  152. as he wants and then let R&R do all the reports at once. 
  153.  
  154. I don't know if you use Blinker 2.0 or not but there is a new function 
  155. that does the same thing as RRUNTIME.exe.  This function is called 
  156. SWPRUNCMD() and is faster than RRUNTIME. 
  157.  
  158. Instead of     RUN RRUNTIME RRUNIN 
  159. You could use  SWPRUNCMD("RRUNTIME RRUNIN",0,"","") 
  160. which would work OK but would cause redundant swapping; 
  161. I use          SWPRUNCMD("RRUN RRUNIN",0,"","") 
  162. which brings in R&R a lot faster than RRUNTIME. 
  163.  
  164. Just thought you would like to know. 
  165.  
  166. --Art 
  167.  
  168.  
  169. ▀ Message Sent Via THE INTERCOM ver. 1.09 Zachary Speaks! ▀ 
  170.  
  171. To:   DENNIS COURTNEY          
  172. From: RICHARD HAMILTON         
  173. Subj: R&R CG FUNC. & GENERAL   
  174. Conf: ZACHARY 5 (2)                 Msg # 1533   
  175. Date: 05/20/92                      (PUBLIC)
  176.  
  177. Dennis, 
  178.  
  179. A couple of things you should know regarding R&R... 
  180.  
  181. 1. Don't call runtime with the RRUNTIME call if you're using 
  182. Overlay(). Use RRUN instead, same parameters. 
  183.  
  184. 2. R&R recreates the database by writing the selected data out to 
  185. file, then prints from that data. Disk caching software will speed 
  186. that process up considerably. 
  187.  
  188. Richard 
  189.  
  190.  
  191. ▀ Message Sent Via THE INTERCOM ver. 1.09a Zachary Speaks! ▀ 
  192.  
  193. To:   DICK BERTI               
  194. From: RICHARD HAMILTON         
  195. Subj: ZACHARY SPEAKS PROBS     
  196. Conf: MAIN BOARD (0)                Msg # 4035   
  197. Date: 05/06/92                      (PRIVATE)
  198.  
  199. Dick, 
  200.  
  201. Implementing a complete R&R interface in a Zachary Application: 
  202.  
  203. 1. Create a B-type option and import the field structures from the 
  204. RRUNIN file. I generally make this a hot key procedure rather than 
  205. a menu option so it's available only by the secret hot-key. Here you 
  206. can directly edit RRUNIN fields as desired, set up new reports, and 
  207. (most important) teach Zach what the RRUNIN file is! 
  208.  
  209. 2. Create an E-option from which to run reports. Use a field for 
  210. report name and use File Validation into the RRUNIN file to select the 
  211. desired report name. 
  212.  
  213. 3. Put an extra field in the RRUNIN file in which you can code the 
  214. desired parameter edits for a particular report (This keeps the system 
  215. flexible). For example, a field named UPDATES could carry codes like: 
  216.    INVDATE -- Indicating an edit to the scope specs for Invoice date.
  217.    CUST -- Indicating that you will select the customer for the
  218.    report.
  219.    or, INVDATE/CUST would indicate you would check both!
  220.  
  221. 4. Set up the necessary fields in the E-procedure to get user input 
  222. for the job specs, Use standard Zachary validations, File validation, 
  223. etc., to get data input right. Use Condition For Access to limit edits 
  224. to the appropriate fields ("INVDATE"$RRUNIN->UPDATES). Remember to get 
  225. the printer spec... you can use a Zachary O-type for this. (And if you 
  226. allow writing to a file, get the file name.) 
  227.  
  228. 5. Set up additional fields to take the user input and re-form it to 
  229. the character strings you want to replace into the RRUNIN file. 
  230. Specify updates to RRUNIN. 
  231.  
  232. 6. Write a user field to be executed AFTER UPDATE that will make the 
  233. call to R&R Runtime, like you normally would. I always use Greg 
  234. Martin's OVERLAY() library to maximize memory available. Remember 
  235. you'll need to save and restore the screen. 
  236.  
  237. I've used this technique a number of times in applications and it 
  238. works great... it's especially nice for situations when you go back 
  239. into the field to add or edit a report, provided you have the proper 
  240. edits available. I've even had occasion to add RRUNIN fields for 
  241. listing code blocks with functions to run before and after the R&R 
  242. call. You can do almost anything then, provided you linked in adequate 
  243. functions! 
  244.  
  245. We've found the R&R system, with RRUNIN.DBF defined in Zach, works 
  246. great because you can then do the reports with an E-procedure and look 
  247. up things like the report name from the RRUNIN via a standard Zach 
  248. file validation. 
  249.  
  250. Hide the RRUNIN itself from the user by making it a rather elusive hot 
  251. key (like ALT-F5) and if you want more protection add either a 
  252. complete security system or a little tiny one known only to you, such 
  253. as a condition for access: 
  254.  
  255. if(zget(23,2,'    ','Enter Password','@!')='RHOK',.t., 
  256. zerrorbeep('Invalid Password')) 
  257.  
  258. (This, of course, is all typed on one line in the Condition for Access 
  259. field.) 
  260.  
  261. This worked very well for us, although the password is hard-coded 
  262. (RHOK), but if someone really wants to get in and screw things up I'm 
  263. sure they could anyway, what with dBase and all. 
  264.  
  265. Richard 
  266.  
  267.  
  268. ▀ Message Sent Via THE INTERCOM ver. 1.09a Zachary Speaks! ▀ 
  269.  
  270. To save your screens from death upon return from an R&R report
  271. called from a U_type field, use the following format in the U-type
  272. field:
  273.  
  274. save screen
  275.  
  276. <call the R&R report>
  277.  
  278. restore screen
  279.  
  280.  
  281.  
  282.  
  283. To:   LEN DOZOIS               
  284. From: STEPHEN REED             
  285. Subj: ZACH 2 WISH              
  286. Conf: MAIN BOARD (0)                Msg # 7243   
  287. Date: 09/10/92                      (PUBLIC)
  288.  
  289. A suggestion for zach 2, would it be possible to be able to use special 
  290. indexes through RDD such as the new one from nantucket. 
  291. I am currently using the E procedure to create a temporary file which I 
  292. than send to RR to print.  If I could just define a sub index for RR it 
  293. would be MUCH faster and my customer would not be nearly SO UNHAPPY. 
  294.  
  295. Also for your information I recently installed a Summer 87 application 
  296. on my first Novell Lite Installation.  Had some very strange problems 
  297. having to do with looking at a data base file.  Finally changed to 
  298. Lantastic Ethernet Installation and the problems went away.  Beware of 
  299. Novell Lite and Clipper Applications!!! 
  300.  
  301.  
  302. ▀ Message Sent Via THE INTERCOM ver. 1.09 Zachary Speaks! ▀ 
  303.